• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The invention relates to a method of transmitting a message, said message from a server (SvrM) of a merchant (Mct), who wishes to transmit this information to a user (Usr) having a terminal of communication (CT). According to this method, said message is transmitted indirectly to said communication terminal (CT) by using at least one server-specific data transmission service (SvrIBK) of a banking establishment (IssuBK) with which said user (Usr) has a bank account.
    公开号:FR3041132A1
    申请号:FR1558451
    申请日:2015-09-11
    公开日:2017-03-17
    发明作者:Vincent Ducrohet
    申请人:Ingenico Group SA；
    IPC主号:
    专利说明:

    Related data transmission method, devices and computer programs 1. Domain
    The proposed technique relates to the transmission of data to users by traders. The proposed technique relates more specifically to the transmission to a user by a merchant of data representative of information relating to a purchase made by the user from the merchant. 2. Prior Art
    The communication between a merchant and a user is an essential element to make a purchase. The merchant must first communicate his offer (a product materialized or immaterialized, and a price). The user gives his acceptance and makes the payment, for example by using his credit card. Thereafter, the merchant provides a receipt in the form of a ticket that indicates the amount of payment and the product or service purchased. This receipt, on the one hand, makes it possible to confirm the amount actually invoiced and to justify the purchase, and on the other hand enables the merchant to give the user information on the product actually purchased.
    The receipt is an information medium that happens to be in paper form. Merchants must be equipped with a printer or a terminal incorporating a printer to print these receipts. The purchase and maintenance of printers or terminals represents an additional burden for merchants. In addition, the massive use of paper poses an ecological problem.
    For certain types of sales (eg online sales), receipts are often in electronic form. After a purchase, the merchant sends a receipt or confirmation of the order to the user by email (email). To do this, the merchant must either maintain a database of users' contact details or ask the user to provide his email address for each purchase. The maintenance of a database of this type (registration, unsubscription, modification, etc.) is complex and expensive for merchants. In addition, users must update their contact information with merchants, which is problematic in some cases. In addition, users must log in to merchant systems. This leads to an inconvenient delay, especially for fast purchases.
    In addition, the modes of sale of products or services evolve and allow users to make purchases in a simplified way. These modes of sales have points in common: speed of product choice and payment targeting impulse buying; ability to transact with high usage peaks; point of sale minimized to be deployed quickly and in disparate environments; point of sale reducing the overall cost of ownership (TCO);
    To cover all of these points of sale, it is possible to integrate payment in a touch screen for example. The final solution will achieve an on-screen application for product selection and payment terminal to pay in contactless, NFC or other electronic payment method. In these cases of use, it is necessary to provide a receipt (ticket) after each purchase of the users. In fact, for purchases of dematerialized products (for example, a cinema session), it is necessary to indicate the information that enables users to access the products (time, room and place). For the purchase of the materialized products, it is necessary to indicate means allowing the users to recover the products or to provide their addresses for the shipments of the products.
    For issues of cost, maintenance (paper) and waiting times, the solution with printed receipts does not adapt to the massive deployment of outlets. The solution with electronic receipts previously described for online purchases can dematerialize receipts and avoid the use of printers. However, it requires input devices (to identify users or to enter coordinates) and / or the now databases of user coordinates. This results in additional time (time for user identification or entry of contact information) for purchases, and additional cost for equipment. Moreover, in the case where the user must enter his contact information, there is a risk of disclosure and / or abuse by merchants.
    There is therefore a need to provide a solution that communicates information to users after purchases, which addresses issues of complexity, cost, speed and security. 3. Summary
    The proposed technique does not present at least some of the problems of the prior art. More particularly, the proposed technique relates to a method of transmitting a message, said message from a server of a merchant, who wishes to transmit this message to a user having a communication terminal, said method being characterized in that at least part of the content of said message is transmitted indirectly to said communication terminal by using at least one data transmission service specific to a server of a banking establishment with which said user has a bank account.
    Thus, the method reuses the existing infrastructure of financial institutions to transmit data from a merchant to users. It is no longer necessary for merchants to have the coordinates of the users in order to transmit them data.
    According to a particular characteristic, said data transmission service implements a telephone number of said user.
    According to a particular characteristic, said data transmission service implements an application of the banking establishment, said application being installed on a communication terminal of said user.
    According to a particular embodiment, said data transmission service is of the "3D-Secure ™" type. Thus, the method can be used for most financial institutions since the 3D-Secure service is widely deployed by financial institutions.
    According to a particular embodiment, said method comprises the following steps, performed after a step of receiving a confirmation of a financial transaction, financial transaction made between said bank of said user and a bank of said merchant: a step of transmitting, to a server of said merchant, a request to obtain said message; a step of receiving, from said server of said merchant, a response containing said message; a step of transmitting, to said communication terminal of said user, a second message comprising at least a part of the content of said message.
    Thus, the transmission method is triggered by a transaction performed by a user. This makes it possible to transmit a message to a user, each time after a transaction performed by the user.
    According to a particular characteristic, said confirmation comprises an identifier of said merchant and an identifier of said transaction.
    Thus, the user's bank can identify the merchant and the transaction. Communication with the merchant's server.
    According to a particular characteristic, said identifier of said merchant includes an IP address or a URL address of the said merchant's server.
    Thus, the server of the user's banking establishment can initiate a communication on the internet with the merchant's server.
    According to a particular embodiment, said message is transmitted to said user in a form adapted to the communication device receiving this message.
    In another embodiment, the technique also relates to a server of a banking establishment for transmitting a message, said message from a merchant, who wishes to transmit this information to a user having a communication terminal, said server comprising: a transmission module, a request for said data, to a server of said merchant; a receiving module, from said server said merchant, said data; a module for transmitting said data to said communication terminal of said user.
    In another embodiment, the technique also relates to a method of indirectly transmitting a message to a user by using at least one data transmission service specific to a server of a banking establishment with which said user has a bank account, said method comprising: a step of receiving, from a server of said bank of said user, a request of said data; a module for transmitting said data to said server of said user's bank.
    In another embodiment, the technique also relates to a server of a merchant for indirectly transmitting a message to a user by using at least one data transmission service specific to a server of a banking establishment at which said user has a bank account, said server comprising: a receiving module, from a server of said bank of said user of a request of said data; a module for transmitting said data to said server of said user's bank.
    According to a preferred implementation, the various steps of the methods according to the proposed technique are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay module according to the technique. proposed and being designed to control the execution of the different process steps.
    Accordingly, the proposed technique is also directed to a program that can be executed by a computer or a data processor, which program includes instructions for controlling the execution of the steps of a method as mentioned above.
    This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
    The proposed technique is also aimed at a data carrier readable by a data processor, and including instructions of a program as mentioned above.
    The information carrier may be any entity or device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard. On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the proposed technique can be downloaded in particular on an Internet type network.
    Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
    According to one embodiment, the proposed technique is implemented by means of software and / or hardware components. In this context, the term "module" may correspond in this document as well to a software component, a hardware component or a set of hardware and software components.
    A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or a program. set of functions, as described below for the module concerned. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, router, etc.) and is capable of accessing the hardware resources of this physical entity (memories, recording media, bus communication cards, input / output electronic cards, user interfaces, etc.).
    In the same way, a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions, as described below for the module concerned. It may be a hardware component that is programmable or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing a firmware ( firmware), etc.
    Each component of the previously described system naturally implements its own software modules.
    The various embodiments mentioned above are combinable with each other for the implementation of the proposed technique. 4. Figures Other features and advantages will appear more clearly on reading the following description of a particular embodiment of the disclosure, given as a simple illustrative and nonlimiting example, and the appended drawings, among which: Figure 1 is a sequence diagram of the method according to the proposed technique; FIG. 2 illustrates the necessary steps of a communication method implemented by the bank of the user; FIG. 3 illustrates the necessary steps of a communication method implemented by the merchant; Figure 4 is a simplified representation of a system of a bank for implementing a communication method; Figure 5 is a simplified representation of a server of a merchant to implement a communication method. 5. Description 5.1. General principle
    In the state of the art, it is complex and expensive for merchants to transmit directly to their client users (subsequently called users or customers for simplicity), messages relating to purchases made or other information. , because of the difficulty and the complexity of the maintenance and / or obtaining the coordinates of the users. An object of the present technique is to allow traders to transmit to their customers information, simple marinar, economic and secure. The present technique makes it possible, for example, to solve the problem of transmitting information to a user when the terminal that is used to make a purchase (payment terminal) does not have a printer (to attest to the materiality of the purchase of the product. one part and the amount paid on the other). This is for example the case of new types of terminals, which can be called integrated terminals (for example to third objects, such as touch screens or not). A terminal is for example integrated within a display panel, which may be provided with a digital display screen (LCD) and before which one or more messages are displayed. These messages may for example ask individuals to make a donation for a charity, a foundation, or make a purchase of goods or services, etc. An autonomous terminal may also be a beverage, candy dispenser, etc.
    In this type of terminal, the means of payment implemented is generally contactless: it may be a contactless payment card or a communication terminal provided with a contactless interface. To make a donation or a purchase, the user just has to present his contactless payment method in front of the integrated terminal. The integrated terminal reads the contactless data (the credit card data for example) and transmits this data to a transaction server that manages the debit of the user's account at the bank card issuing bank. A problem is that the user is not informed immediately of the amount of the transaction. The present technique solves this problem. Another problem, also solved by the present technique, is that the operator of the integrated payment terminal (the merchant) can not inform the user (for example to thank him for a donation). To solve this problem, and other more general concerns about the communication between a client user and a merchant, the present technique uses an existing architecture (that of the banking network), to establish this communication between the user and the merchant and this, without the need for data entry by the user.
    The general principle of the proposed technique is therefore to take advantage of existing banking systems in the state of the art. Banks maintain, for their own purposes, databases with contact information for their clients, in order to communicate with them if necessary. For example, the "3D Secure" online payment technique requires the bank to know the customer's phone number in order to be able to provide the customer with a "challenge" proving the identity of the user trying to pay. by credit card (the challenge being a code to enter in a given field of a web page). Thus, the proposed technique consists in transmitting data representative of merchants' information (security messages, commercial messages, information messages), indirectly, to users, using a data transmission service of its own. to a server of a banking establishment with which said user has a bank account.
    The main steps of the technique are illustrated in connection with FIG. 1. The participants of the method illustrated in FIG. 1 are: a Usr user equipped with a communication terminal CT and a bank card BC; a merchant Met with a POS payment terminal and a SvrM server; an acquiring bank IssuBK which is a banking establishment with which the merchant has a bank account; and an issuing bank AcquBK which is a banking institution with which the user has a bank account. When the user Usr makes a purchase from a merchant Met, he makes the payment using for example a bank card BC on the POS payment terminal of the merchant Met. The payment terminal POS of the merchant Met transmits 11 a transaction request to a transaction SvrABK server of the banking institution (acquiring bank AcquBK) of the merchant. The transaction request includes in particular information representative of the bank account and / or the bank card of the user (and therefore the issuing bank IssuBK) and the amount of the product purchased by the user. The server of the bank of the merchant SvrABK (acquiring bank AcquBK) validates this transaction (either by requesting authorization from a bank server SvrIBK of the bank of the user IssuBK or independently) and transmits 12 a confirmation of the transaction to this server of the banking institution SvrIBK of IssuBK issuing bank. The confirmation of the transaction may include in particular a merchant identifier and an identifier (or number) of the transaction. The merchant identifier may include an IP address or a URL (or URI) of the Met Merchant SvrM server. This merchant identifier allows, according to the present technique, the banks (issuing bank IssuBK) users to initiate a communication with the merchant Met.
    The SvrABK and SvrIBK servers of the proposed technique may be new dedicated servers for the implementation of the proposed technique. Preferably, they can also take the form of specific modules of transaction processing servers. Thus, it is not necessary to modify the existing technical architecture.
    After receiving a confirmation of the transaction, a server SvrIBK of the bank of the user (issuing bank IssuBK) transmits 13 to the server SvrM of the merchant Met, a request (QWT) for obtaining a message (Msg # l ) intended to be transmitted to the user.
    In response to the request QWT, the server SvrM of the merchant Met transmits 14 to the server SvrIBK of the bank of the user (issuing bank IssuBK), a response (Resp) comprising a message to be transmitted to the user. The request transmitted by the SvrIBK server of the user's banking establishment (issuing bank IssuBK) may include the identifier of the transaction previously made and / or an identifier of the user (for example a Hashé of the credit card number ). The merchant server Met can identify the corresponding purchase of the user from the identifier of the transaction or the hash of the credit card number of the user or a token (token). It can then generate the message containing the information it wishes to transmit (this message is not necessarily linked to the purchase) and place this message (Msg # l) in the response (Resp) to the request (QWT) . The information to be transmitted corresponds for example to the total amount of the purchase made by the Usr user, or to other aspects.
    For example, the server SvrM Met may communicate with the POS payment terminal and / or may have a database including information on all purchases from the merchant Met and information on the corresponding banking transactions. The information generated by the provider SvrM of the merchant Met, destined for the user Usr, can be an informative message on a purchase, a proof of purchase, and / or a commercial message, a security message (for example user account). This last possibility is particularly interesting: the dissemination of a security message by this architecture is efficient and secure, because the message broadcast banking infrastructure is itself secure. Thus, the present technique increases the general level of message transmission security between a merchant and a user. The message to be transmitted to the user may take the form of an image, a text, a 1D or 2D code, or a URL including such information.
    After receiving the message Msg, the server extracts from it, its contents (for example if it is a text) .. From this content (at least part of this content), the SvrIBK server of the user's banking establishment (issuing bank IssuBK) created his own message (second message) Msg # 2 and forwarded it 15 to the user. This second message Msg # 2 is transmitted for example via SMS or MMS (to a communication terminal CT of the Usr user) or via a mobile application notification. The second message Msg # 2 can also be transmitted by email or by using an application (application of the bank installed on a user's communication terminal) or another communication application. The user Usr can thus be informed of the information on the donation, the product or the service he has purchased. In the case of the use of a banking application, the chain of security of the transmission of the message is preserved: indeed the transmission of a notification by the banking application uses a secure channel of transmission of messages that it is difficult to penetrate and defraud. Therefore, the information transmitted by the merchant (and received by the user) has a significant reliability.
    Thus, without the bank having to disclose confidential information of its customer (ie, telephone number, e-mail address, etc.), the merchant can contact him and send him data that it can not usually transmit (because it does not have user information) or it does not want to transmit using a complex and expensive client data management architecture. 5.2. Server of the user's banking establishment (issuing bank) The IssuBK bank of the Usr user has a SvrIBK server which makes it possible to implement a method of transmitting a message to a communication terminal CT of the user. user Usr. The method implemented by the SvrIBK server of the Issu BK banking institution of the Usr user comprises the following steps: a reception step 22, a confirmation of a financial transaction; this financial transaction was carried out between a transaction processing server of the user's IssuBK bank and a transaction server of a merchant's AcquBK bank; this confirmation may comprise an identifier of the merchant Met comprising an IP address or a URL address of a server SvrM of the merchant Met, and allowing a server SvrIBK of the bank IssuBK of the user to initiate a communication with the server SvrM of the merchant Met; the confirmation may also include an identifier (or number) of the transaction; indeed, the merchant Met also has this transaction identifier in his SvrM server for any financial or legal checks or controls. a transmission step 13, to the server SvrM of the merchant Met, a request of the obtaining message; the content of this message is intended to be transmitted to a communication terminal CT of the user; the request may include the identifier of the transaction; indeed, the merchant Met has a database that includes information on purchases and the corresponding banking transactions; the transaction identifier thus makes it possible, according to the present technique, for the merchant Met to identify the purchase or purchases corresponding to the transaction and to generate a message corresponding to the purchase or purchases made by the user; a receiving step 24, from the server SvrM of the merchant Met, the message generated by the merchant; the message in question is not necessarily related to the purchase; it can be, but it can also be other messages (for example a security message relating to the account of the user at the merchant); this type of message transmission is advantageous because it makes it possible to benefit from a secure transmission channel: that of the banking establishment; a step of transmitting the content of the previously received message to the user's CT communication terminal; the content of the first message is inserted in a second message, which is transmitted to the user via the bank channel; this second message is transmitted in the name of the merchant Met.
    Thus, the transmission of data representative of the information on the purchases of the users is ensured by a service of transmission of the users' banking establishments. It is not necessary for users to enter their details or to identify themselves when shopping with merchants (which simplifies the purchase made using an integrated terminal). In addition, the users' contact details are kept by the banks and are not accessible to the merchants. The security of the users' contact details is thus guaranteed. This avoids misuse of these details by merchants (advertising campaigns).
    Figure 4 illustrates a hardware architecture of the SvrIBK server of the bank Usr user. This hardware architecture comprises a memory 41 consisting of a buffer memory, a processing unit 42, equipped for example with a microprocessor, and driven by the computer program 43, implementing the necessary steps of the communication method such as previously described. At initialization, the code instructions of the computer program 43 are for example loaded into a memory before being executed by the processor of the processing unit 42. The microprocessor of the processing unit 42 implements the steps of the transmission method previously described, according to the instructions of the computer program 42. For this, the server of the bank SvrIBK user Usr includes: a transmission module, a SvrM server of a merchant Met, of a request to obtain a message to be transmitted. This message is intended to be transmitted to a communication terminal CT of a Usr user of the merchant Met; a message receiving module, from the SvrM server of the merchant Met; it can be a general module for receiving messages; a transmission module of a message comprising said data to the communication terminal CT of the user Usr; it can be a general module for transmitting messages.
    These modules can be driven by the processor of the processing unit 42 according to the computer program 43. These modules are in the form of software or hardware, specifically or not dedicated to the implementation of the present technique.
    Preferably, the second message is transmitted to a mobile phone of the user in the form of an SMS or MMS type message, using the existing data necessary for the implementation of the security technology "3D Secure". Indeed, the existing infrastructure (servers) of the 3D-Secure technology already implemented by the banks makes it possible to send SMS messages to their customers. 3D-Secure technology is called "Verified by Visa" at Visa, and "SecureCode" at MasterCard. This is a banking protocol that will be used by the merchant during an electronic payment. The purpose of this protocol is to perform a strong authentication of the person who carries out the transaction to ensure that it is the owner of the card used.
    To perform strong authentication, the most used process is as follows: The user enters his payment data on a merchant's web page; the trader initiates a 3D-Secure transaction via his acquirer;
    The issuing bank transmits a dynamic password (OTP: "one-time password" in English) to the user on his mobile phone via an SMS;
    The merchant requests the OTP to the user to validate the transaction (validation of the transaction if the OTP entered corresponds to the one that was sent).
    This process of securing payments on the internet is deployed and used in many countries. As a result, the issuing banks have the mobile phone number of each of their customers and have the tools to maintain this base based on changes in users' phone numbers.
    Thus, the proposed technique can reuse 3D-Secure servers deployed by banks to send SMS messages to users' mobile phones. The cost for the implementation of the proposed technique is therefore greatly reduced. 5.3. Merchant server
    The merchant Met has a SvrM server for implementing a message transmission method indirectly to a Usr user by using at least one data transmission service specific to a SvrIBK server of an IssuBK bank with which said user has a bank account.
    The method implemented by the commercial server SrvM comprises: a reception step 33, of the SvrIBK server of the IssuBK bank of the user Usr, of a request to obtain a message intended to be transmitted to the user Usr; the request may include an identifier of a financial transaction made by the user Usr; the identifier of the transaction enables the merchant Met to identify the purchase corresponding to the transaction and to generate a message corresponding to the purchase made by the user Usr; depending on the embodiments, the request for obtaining the message can have two origins: either this request comes directly from the SvrIBK server of the IssuBK bank of the Usr user, that is to say that the SvrIBK server directly forwarded this request to the SvrM merchant server; either this request comes from the server SvrABK, belonging to the bank of the merchant: the request is then relayed by the server SrvABK and comes indirectly from the server SrvIBK; There may be several reasons for this relay carried out by the merchant's bank server: for example, the merchant's bank does not want the user's bank to interact directly with the merchant (for reasons of data bases). customer) or because the bank of the user does not want to implement a communication infrastructure with the merchants' servers; thus, depending on the embodiments, the step of receiving the obtaining request 33 may be preceded by a step of transmitting an initial request to the server of the merchant's banking establishment; a transmission step 14 of the message to the server SvrIBK IssuBK banking institution Usr user, this message being integrated within a response; the address of the SvrIBK server of the IssuBK bank of the Usr user may be an IP address or a URL address; the IP address can be obtained by the merchant Met, reading the header (in the source address fields) IP frames; the URL can be included in the request transmitted by the SvrIBK server of the IssuBK banking institution of the user Usr; similarly, depending on the embodiments, the response can be relayed via the SrvABK server of the merchant banking institution.
    Figure 5 illustrates a hardware architecture of the SvrM server of the merchant Met. This hardware architecture comprises a memory 51 consisting of a buffer memory, a processing unit 52, equipped for example with a microprocessor, and driven by the computer program 53, implementing the necessary steps of the communication method such as previously described. At initialization, the code instructions of the computer program 53 are for example loaded into a memory before being executed by the processor of the processing unit 52. The microprocessor of the processing unit 52 implements the steps of the transmission method, according to the instructions of the computer program 52. For this, the server SvrM of the merchant Met comprises: a receiving module, from (direct or indirect) a server SvrIBK of the banking establishment IssuBK of a user Usr, a request to obtain a message intended to be transmitted to the user Usr; a module for transmitting the data to the SvrIBK server of the banking establishment
    IssuBK of the user.
    These modules can be driven by the processor of the processing unit 52 according to the computer program 53. These modules are in the form of software or hardware, specifically or not dedicated to the implementation of the present technique. 5.4. Description of a use case
    An embodiment of the method proposed when buying a movie ticket on a self-service kiosk (or donation) is described below. This self-service kiosk (for sale or donation to an association for example) includes an integrated payment terminal.
    In this example, it is considered to be a self-service kiosk selling movie tickets. The self-service kiosk includes a touch screen and a POS payment terminal with NFC functionality. On the touch screen, the available movie sessions and the corresponding rates are displayed. The user can choose a session of a film and a place on the touch screen of the terminal. To make the payment, the user can simply pass a payment card or a mobile phone equipped with NFC in front of a detection area of the POS payment terminal. A transaction request for the benefit of the merchant is then transmitted to a transaction server of the merchant's bank (acquiring bank AcquBK). The transaction store's transaction server AcquBK Met validates the transaction and transmits a confirmation of the transaction to a server of the bank of the user (issuing bank IssuBK). This confirmation can include a number of the transaction made and a URL of the SvrM server of the merchant. Of course, the debtor account in the transaction is the user's account with IssuBk issuing bank. The SvrIBK server of the user's bank (issuing bank) can access a database containing the details of its customers. The SvrIBK server of the bank Usr user can search the database and obtain the mobile phone number of the user from the account number of the user Usr.
    After receiving the confirmation of the transaction, the server SvrIBK server Usr can issue a request to the URL address of the server SvrM of the merchant Met to ask the merchant Met to provide the content of a message intended for to be sent to the user Usr. The request can include the number of the transaction that has just been confirmed. Upon receipt of the request, the Met merchant SvrM server identifies the purchase corresponding to the transaction number provided in the request, and generates a message indicating the ticket number, the billed amount, the address of the cinema (if necessary ), the session and / or the room number and / or the place. The message may include a link, hypertext type, to obtain detailed information (synopsis and photos of the film, 2D code of the ticket to facilitate control, etc.) on the movie ticket. This message is subsequently transmitted to the SvrIBK server of the IssuBK bank of the Usr user. Upon receipt of the message, the server SvrIBK IssuBK bank of the user Usr can directly transmit the message to the mobile phone of the user by SMS, MMS or any other suitable message transmission means (for example a notification of mobile app). The bank IssuBK can also check the accuracy of the amount invoiced in the message before transmitting it to the user Usr. If the amount billed in the message does not match the amount of the transaction confirmed, the SvrIBK server of the user's IssuBK bank can notify the user by SMS. This allows the bank and the user to detect possible fraudulent traders.
    权利要求:
    Claims (11)
    [1" id="c-fr-0001]
    1. Method for transmitting a message, said message from a server (SvrM) of a merchant (Met), who wishes to transmit this message to a user (Usr) having a communication terminal (CT), said method being characterized in that at least a part of the content of said message is transmitted indirectly to said communication terminal (CT) by using at least one server-specific data transmission service (SvrIBK) of a banking establishment ( IssuBK) from which said user (Usr) has a bank account.
    [2" id="c-fr-0002]
    2. Method according to claim 1, characterized in that said data transmission service implements a telephone number of said user.
    [3" id="c-fr-0003]
    3. Method according to claim 1, characterized in that said data transmission service implements an application of the bank (IssuBK), said application being installed on a communication terminal of said user.
    [4" id="c-fr-0004]
    4. Method according to claim 1, characterized in that it comprises the following steps, performed after a step of receiving a confirmation of a financial transaction, financial transaction made between said bank (IssuBK) of said user (Usr ) and a bank (AcquBK) of said merchant (Met): a step of transmitting, to a server (SvrM) of said merchant (Met), a request to obtain said message; a step of receiving, from said server (SvrM) of said merchant (Met), a response (Resp) containing said message; a step of transmitting, to said communication terminal (CT) of said user (Usr), a second message (Msg # 2) comprising at least part of the content of said message (Msg # 1).
    [5" id="c-fr-0005]
    5. Method according to claim 4, characterized in that said confirmation comprises an identifier of said merchant and an identifier of said transaction.
    [6" id="c-fr-0006]
    6. Transmission method according to claim 5, characterized in that said identifier of said merchant comprises an IP address or a URL address of said merchant's server.
    [7" id="c-fr-0007]
    7. Transmission method according to one of claims 1 to 6, characterized in that said message is transmitted to said user in a form adapted to the communication device receiving this message.
    [8" id="c-fr-0008]
    8. Server of a banking establishment for transmitting a message, said message from a merchant, who wishes to transmit this information to a user having a communication terminal, said server being characterized in that said server comprises: a module transmitting a request for said data to a server of said merchant; a receiving module, from said server said merchant, said data; a module for transmitting said data to said communication terminal of said user.
    [9" id="c-fr-0009]
    A method of indirectly transmitting a message to a user using at least one data transmission service specific to a server of a banking establishment with which said user has a bank account, said method being characterized in that it comprises: a step of receiving, from a server of said bank of said user, a request for said data; a module for transmitting said data to said server of said user's bank.
    [10" id="c-fr-0010]
    A merchant's server for indirectly transmitting a message to a user using at least one data transmission service specific to a server of a banking establishment with which said user has a bank account, said server being characterized in what it comprises: a reception module, coming from a server of said bank of said user of a request of said data; a module for transmitting said data to said server of said user's bank.
    [11" id="c-fr-0011]
    11. Computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of a communication method according to claim 1 or claim 9, when executed by a processor.
    类似技术:
    公开号 | 公开日 | 专利标题
    EP0820620B1|1999-03-17|Electronic payment method for purchase-related transactions over a computer network
    US9911150B2|2018-03-06|Alternative email-based website checkouts
    US20100299212A1|2010-11-25|System and method for a commerce window application for computing devices
    EP3142054A1|2017-03-15|Data transmission method with corresponding devices and computer programs
    US20120310774A1|2012-12-06|Electronic payment system
    US20150052055A1|2015-02-19|System and method utilizing a one-to-many payment button for completing a financial transaction
    WO2013001072A1|2013-01-03|Method of secure compensation of grouped promotional sales with variable rate and system for implementing same
    EP3349160A1|2018-07-18|Method of transmitting data, corresponding device and program
    EP2824625B1|2021-02-17|Method for conducting a transaction, corresponding terminal and computer program
    EP3382628A1|2018-10-03|Method for data processing by a payment terminal, corresponding payment terminal and program
    WO2019002703A1|2019-01-03|Checking of validity of a remote payment interface
    FR2823882A1|2002-10-25|Commercial transaction using prepayment card over the Internet, uses personal computer or mobile phone, certification center validates data contained on prepayment card
    EP2800072A2|2014-11-05|Method for issuing SIM mobile telephone cards with prepaid or postpaid subscription by an automaton
    EP3349161A1|2018-07-18|Method of handling a payment trnsaction, corresponding payment terminal and program
    KR20220017790A|2022-02-14|Real-time bankbook deposit confirmation system using mobile push notification
    BE1014305A7|2003-08-05|Universal pre-paid payment card for making payment over telecommunication networks, uses pre-paid card with scratch-off strip covering unique code that is sent by user to make purchase
    WO2021053300A1|2021-03-25|Method for transmitting a complementary information relating to a financial transaction
    FR3012239A1|2015-04-24|METHOD AND DEVICE FOR CREATING AND PROVIDING ACCESS TO PERSONALIZED ONLINE SALES SPACES
    FR3038766A1|2017-01-13|PAYMENT WITH SECURE QR CODE
    FR2912579A1|2008-08-15|SECURE TRANSFER METHOD THROUGH A MONETARY FLOW COMMUNICATION NETWORK, TRANSFER SYSTEM AND PROGRAM PRODUCT THEREOF
    WO2013054058A1|2013-04-18|Method of carrying out an electronic transaction
    CA2946145A1|2015-10-22|Methods for processing transactional data, and corresponding devices and programs
    FR2976385A1|2012-12-14|Method for defining transaction to be carried out to purchase product in shop, involves obtaining transaction objective specification by server via one of three communications, where second communication includes reference to specification
    FR2981480A1|2013-04-19|Method for performing electronic transaction of service between e.g. automatic cash register and mobile phone through server, involves sending confirmation of electronic transaction from server toward terminals
    FR2857126A1|2005-01-07|Electronic transaction method, involves verifying integrity of data contained in uniform resource locator using digital authenticator by comparing private keys to make online payment and confirming acceptance of payment to user or vendor
    同族专利:
    公开号 | 公开日
    US10929825B2|2021-02-23|
    EP3142054A1|2017-03-15|
    US20170076261A1|2017-03-16|
    CA2941310A1|2017-03-11|
    FR3041132B1|2021-01-15|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20020107791A1|2000-10-06|2002-08-08|Nobrega Ryan J.|Method and apparatus for performing a credit based transaction between a user of a wireless communications device and a provider of a product or service|
    GB2398159A|2003-01-16|2004-08-11|David Glyn Williams|Electronic payment authorisation using a mobile communications device|
    EP1916623A1|2006-10-25|2008-04-30|Compagnie Industrielle et Financiere d'Ingenierie Sociéte Anonyme|Method of supplying transaction details, corresponding terminal, transaction method, method of enhancing bank statements, server, signal and computer program products.|
    US20120203700A1|2010-12-10|2012-08-09|Electronic Payment Exchange|Tokenized contactless payments for mobile devices|
    WO2015100385A1|2013-12-27|2015-07-02|Square, Inc.|Card reader emulation for cardless transactions|EP3382628A1|2017-03-31|2018-10-03|Ingenico Group|Method for data processing by a payment terminal, corresponding payment terminal and program|US8099368B2|2008-11-08|2012-01-17|Fonwallet Transaction Solutions, Inc.|Intermediary service and method for processing financial transaction data with mobile device confirmation|
    US20100257066A1|2009-04-06|2010-10-07|Bank Of America Corporation|Electronic receipts collection and management system|
    US9105027B2|2009-05-15|2015-08-11|Visa International Service Association|Verification of portable consumer device for secure services|CN108596581B|2017-12-04|2020-08-18|阿里巴巴集团控股有限公司|Verification method and device for resource transfer and electronic payment verification method and device|
    FR3076036A1|2017-12-22|2019-06-28|Orange|METHOD, DEVICE AND PROGRAM FOR MANAGING PURCHASING EVIDENCE|
    法律状态:
    2016-09-27| PLFP| Fee payment|Year of fee payment: 2 |
    2017-03-17| PLSC| Publication of the preliminary search report|Effective date: 20170317 |
    2017-09-28| PLFP| Fee payment|Year of fee payment: 3 |
    2018-09-27| PLFP| Fee payment|Year of fee payment: 4 |
    2019-09-26| PLFP| Fee payment|Year of fee payment: 5 |
    2020-09-25| PLFP| Fee payment|Year of fee payment: 6 |
    2021-09-24| PLFP| Fee payment|Year of fee payment: 7 |
    2022-01-07| TP| Transmission of property|Owner name: BANKS AND ACQUIRERS INTERNATIONAL HOLDING, FR Effective date: 20211202 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1558451A|FR3041132B1|2015-09-11|2015-09-11|DATA TRANSMISSION PROCESS, CORRESPONDING COMPUTER DEVICES AND PROGRAMS|FR1558451A| FR3041132B1|2015-09-11|2015-09-11|DATA TRANSMISSION PROCESS, CORRESPONDING COMPUTER DEVICES AND PROGRAMS|
    EP16187144.7A| EP3142054A1|2015-09-11|2016-09-02|Data transmission method with corresponding devices and computer programs|
    CA2941310A| CA2941310A1|2015-09-11|2016-09-09|Method for transmitting data, corresponding devices and computer programs|
    US15/261,057| US10929825B2|2015-09-11|2016-09-09|Method for transmitting data, corresponding devices and computer programs|
    [返回顶部]